Ovladavanje JavaScript Module Federationom: Moć dijeljenog opsega i dijeljenja ovisnosti

U brzo razvijajućem svijetu web razvoja, izgradnja skalabilnih aplikacija koje se lako održavaju često uključuje primjenu sofisticiranih arhitektonskih obrazaca. Među njima, koncept mikro-frontendova dobio je značajnu popularnost, omogućujući timovima da neovisno razvijaju i implementiraju dijelove aplikacije. U središtu omogućavanja besprijekorne integracije i učinkovitog dijeljenja koda između ovih neovisnih jedinica nalazi se Webpackov Module Federation dodatak, a ključna komponenta njegove snage je dijeljeni opseg (shared scope).

Ovaj sveobuhvatni vodič duboko uranja u mehanizam dijeljenog opsega unutar JavaScript Module Federationa. Istražit ćemo što je to, zašto je ključan za dijeljenje ovisnosti, kako funkcionira i praktične strategije za njegovu učinkovitu implementaciju. Naš cilj je opremiti programere znanjem kako bi iskoristili ovu moćnu značajku za poboljšane performanse, smanjene veličine paketa (bundle) i bolje iskustvo programera u različitim globalnim razvojnim timovima.

Što je JavaScript Module Federation?

Prije nego što zaronimo u dijeljeni opseg, ključno je razumjeti temeljni koncept Module Federationa. Predstavljen s Webpackom 5, Module Federation je rješenje za vrijeme izgradnje (build-time) i vrijeme izvođenja (run-time) koje omogućuje JavaScript aplikacijama dinamičko dijeljenje koda (poput biblioteka, okvira ili čak cijelih komponenti) između zasebno kompajliranih aplikacija. To znači da možete imati više različitih aplikacija (često nazivanih 'udaljenima' ili 'potrošačima') koje mogu učitavati kod iz 'kontejnerske' ili 'domaćinske' aplikacije, i obrnuto.

Glavne prednosti Module Federationa uključuju:

• Dijeljenje koda: Uklonite suvišan kod u više aplikacija, smanjujući ukupne veličine paketa i poboljšavajući vrijeme učitavanja.
• Neovisna implementacija: Timovi mogu neovisno razvijati i implementirati različite dijelove velike aplikacije, potičući agilnost i brže cikluse izdanja.
• Tehnološka agnostičnost: Iako se prvenstveno koristi s Webpackom, u određenoj mjeri olakšava dijeljenje između različitih alata za izgradnju ili okvira, promičući fleksibilnost.
• Integracija u stvarnom vremenu: Aplikacije se mogu sastavljati u stvarnom vremenu, omogućujući dinamička ažuriranja i fleksibilne strukture aplikacija.

Problem: Suvišne ovisnosti u mikro-frontendovima

Razmotrimo scenarij u kojem imate više mikro-frontendova koji svi ovise o istoj verziji popularne UI biblioteke poput Reacta, ili biblioteke za upravljanje stanjem poput Reduxa. Bez mehanizma za dijeljenje, svaki mikro-frontend bi u svoj paket uključio vlastitu kopiju tih ovisnosti. To dovodi do:

• Napuhanih veličina paketa: Svaka aplikacija nepotrebno duplicira uobičajene biblioteke, što dovodi do većih veličina preuzimanja za korisnike.
• Povećane potrošnje memorije: Više instanci iste biblioteke učitanih u pregledniku može trošiti više memorije.
• Nedosljednog ponašanja: Različite verzije dijeljenih biblioteka u različitim aplikacijama mogu dovesti do suptilnih grešaka i problema s kompatibilnošću.
• Potraćenih mrežnih resursa: Korisnici bi mogli preuzeti istu biblioteku više puta ako se kreću između različitih mikro-frontendova.

Tu na scenu stupa dijeljeni opseg Module Federationa, nudeći elegantno rješenje za ove izazove.

Razumijevanje dijeljenog opsega Module Federationa

Dijeljeni opseg, često konfiguriran putem opcije shared unutar Module Federation dodatka, je mehanizam koji omogućuje da više neovisno implementiranih aplikacija dijeli ovisnosti. Kada je konfiguriran, Module Federation osigurava da se jedna instanca određene ovisnosti učita i stavi na raspolaganje svim aplikacijama koje je zahtijevaju.

U svojoj srži, dijeljeni opseg funkcionira stvaranjem globalnog registra ili kontejnera za dijeljene module. Kada aplikacija zatraži dijeljenu ovisnost, Module Federation provjerava taj registar. Ako je ovisnost već prisutna (tj. učitana od strane druge aplikacije ili domaćina), koristi se ta postojeća instanca. U suprotnom, učitava ovisnost i registrira je u dijeljenom opsegu za buduću upotrebu.

Konfiguracija obično izgleda ovako:

            // webpack.config.js

const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ... ostale webpack konfiguracije
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      remotes: {
        'app1': 'app1@http://localhost:3001/remoteEntry.js',
        'app2': 'app2@http://localhost:3002/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Ključne opcije konfiguracije za dijeljene ovisnosti:

• singleton: true: Ovo je možda najkritičnija opcija. Kada je postavljena na true, osigurava da se učita samo jedna instanca dijeljene ovisnosti u svim aplikacijama koje je koriste. Ako više aplikacija pokuša učitati istu singleton ovisnost, Module Federation će im pružiti istu instancu.
• eager: true: Prema zadanim postavkama, dijeljene ovisnosti se učitavaju lijeno (lazily), što znači da se dohvaćaju tek kada se eksplicitno uvezu ili koriste. Postavljanje eager: true prisiljava ovisnost da se učita čim se aplikacija pokrene, čak i ako se ne koristi odmah. To može biti korisno za kritične biblioteke poput okvira kako bi se osiguralo da su dostupne od samog početka.
• requiredVersion: '...': Ova opcija specificira potrebnu verziju dijeljene ovisnosti. Module Federation će pokušati uskladiti traženu verziju. Ako više aplikacija zahtijeva različite verzije, Module Federation ima mehanizme za rješavanje toga (o čemu će biti riječi kasnije).
• version: '...': Možete eksplicitno postaviti verziju ovisnosti koja će biti objavljena u dijeljenom opsegu.
• import: false: Ova postavka govori Module Federationu da ne uključuje automatski dijeljenu ovisnost u paket. Umjesto toga, očekuje da će biti osigurana eksterno (što je zadano ponašanje kod dijeljenja).
• packageDir: '...': Specificira direktorij paketa iz kojeg se rješava dijeljena ovisnost, korisno u monorepo-ima.

Kako dijeljeni opseg omogućuje dijeljenje ovisnosti

Razložimo proces na praktičnom primjeru. Zamislite da imamo glavnu 'kontejnersku' aplikaciju i dvije 'udaljene' aplikacije, `app1` i `app2`. Sve tri aplikacije ovise o `react` i `react-dom` verziji 18.

Scenarij 1: Kontejnerska aplikacija dijeli ovisnosti

U ovom uobičajenom postavu, kontejnerska aplikacija definira dijeljene ovisnosti. Datoteka `remoteEntry.js`, generirana od strane Module Federationa, izlaže te dijeljene module.

Webpack konfiguracija kontejnera (`container/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'container',
      filename: 'remoteEntry.js',
      exposes: {
        './App': './src/App',
      },
      shared: {
        'react': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          eager: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Sada će `app1` i `app2` koristiti ove dijeljene ovisnosti.

Webpack konfiguracija za `app1` (`app1/webpack.config.js`):

            const { ModuleFederationPlugin } = require('webpack');

module.exports = {
  // ...
  plugins: [
    new ModuleFederationPlugin({
      name: 'app1',
      filename: 'remoteEntry.js',
      exposes: {
        './Feature1': './src/Feature1',
      },
      remotes: {
        'container': 'container@http://localhost:3000/remoteEntry.js',
      },
      shared: {
        'react': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
        'react-dom': {
          singleton: true,
          requiredVersion: '^18.0.0',
        },
      },
    }),
  ],
};

            

              
                Copy
              
            
          

Webpack konfiguracija za `app2` (`app2/webpack.config.js`):

Konfiguracija za `app2` bila bi slična onoj za `app1`, također deklarirajući `react` i `react-dom` kao dijeljene s istim zahtjevima za verziju.

Kako to funkcionira u stvarnom vremenu:

1. Kontejnerska aplikacija se prva učitava, čineći svoje dijeljene `react` i `react-dom` instance dostupnima u svom Module Federation opsegu.
2. Kada se `app1` učita, ona traži `react` i `react-dom`. Module Federation u `app1` vidi da su označeni kao dijeljeni i `singleton: true`. Provjerava globalni opseg za postojeće instance. Ako ih je kontejner već učitao, `app1` ponovno koristi te instance.
3. Slično, kada se `app2` učita, također ponovno koristi iste `react` i `react-dom` instance.

To rezultira time da se samo jedna kopija `react` i `react-dom` učitava u preglednik, značajno smanjujući ukupnu veličinu preuzimanja.

Scenarij 2: Dijeljenje ovisnosti između udaljenih aplikacija

Module Federation također omogućuje udaljenim aplikacijama da međusobno dijele ovisnosti. Ako `app1` i `app2` koriste biblioteku koju kontejner *ne* dijeli, i dalje je mogu dijeliti ako je obje deklariraju kao dijeljenu u svojim konfiguracijama.

Primjer: Recimo da `app1` i `app2` koriste uslužnu biblioteku `lodash`.

Webpack konfiguracija za `app1` (dodavanje lodasha):

            
// ... unutar ModuleFederationPlugin za app1
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

Webpack konfiguracija za `app2` (dodavanje lodasha):

            
// ... unutar ModuleFederationPlugin za app2
shared: {
  // ... react, react-dom
  'lodash': {
    singleton: true,
    requiredVersion: '^4.17.21',
  },
},

            

              
                Copy
              
            
          

U ovom slučaju, čak i ako kontejner eksplicitno ne dijeli `lodash`, `app1` i `app2` će uspjeti podijeliti jednu instancu `lodasha` između sebe, pod uvjetom da se učitavaju u istom kontekstu preglednika.

Rukovanje neusklađenostima verzija

Jedan od najčešćih izazova u dijeljenju ovisnosti je kompatibilnost verzija. Što se događa kada `app1` zahtijeva `react` v18.1.0, a `app2` zahtijeva `react` v18.2.0? Module Federation pruža robusne strategije za upravljanje ovim scenarijima.

1. Strogo podudaranje verzija (Zadano ponašanje za `requiredVersion`)

Kada specificirate preciznu verziju (npr. '18.1.0') ili strogi raspon (npr. '^18.1.0'), Module Federation će to provoditi. Ako aplikacija pokuša učitati dijeljenu ovisnost s verzijom koja ne zadovoljava zahtjev druge aplikacije koja je već koristi, to može dovesti do grešaka.

2. Rasponi verzija i rezervne opcije (Fallbacks)

Opcija requiredVersion podržava raspone semantičkog verziranja (SemVer). Na primjer, '^18.0.0' znači bilo koju verziju od 18.0.0 do (ali ne uključujući) 19.0.0. Ako više aplikacija zahtijeva verzije unutar ovog raspona, Module Federation će obično koristiti najvišu kompatibilnu verziju koja zadovoljava sve zahtjeve.

Razmotrite ovo:

• Kontejner: shared: { 'react': { requiredVersion: '^18.0.0' } }
• `app1`: shared: { 'react': { requiredVersion: '^18.1.0' } }
• `app2`: shared: { 'react': { requiredVersion: '^18.2.0' } }

Ako se kontejner prvi učita, uspostavlja `react` v18.0.0 (ili koju god verziju zapravo sadrži). Kada `app1` zatraži `react` s `^18.1.0`, može doći do greške ako je verzija kontejnera niža od 18.1.0. Međutim, ako se `app1` prvi učita i pruži `react` v18.1.0, a zatim `app2` zatraži `react` s `^18.2.0`, Module Federation će pokušati zadovoljiti zahtjev `app2`. Ako je instanca `react` v18.1.0 već učitana, mogla bi baciti grešku jer v18.1.0 ne zadovoljava `^18.2.0`.

Da bi se to ublažilo, najbolja praksa je definirati dijeljene ovisnosti s najširim prihvatljivim rasponom verzija, obično u kontejnerskoj aplikaciji. Na primjer, korištenje '^18.0.0' omogućuje fleksibilnost. Ako određena udaljena aplikacija ima čvrstu ovisnost o novijoj patch verziji, trebala bi biti konfigurirana da eksplicitno pruži tu verziju.

3. Korištenje `shareKey` i `shareScope`

Module Federation također vam omogućuje kontrolu ključa pod kojim se modul dijeli i opsega u kojem se nalazi. To može biti korisno za napredne scenarije, kao što je dijeljenje različitih verzija iste biblioteke pod različitim ključevima.

4. Opcija `strictVersion`

Kada je strictVersion omogućeno (što je zadano za requiredVersion), Module Federation baca grešku ako se ovisnost ne može zadovoljiti. Postavljanje strictVersion: false može omogućiti blaže rukovanje verzijama, gdje Module Federation može pokušati koristiti stariju verziju ako novija nije dostupna, ali to može dovesti do grešaka u stvarnom vremenu.

Najbolje prakse za korištenje dijeljenog opsega

Da biste učinkovito iskoristili dijeljeni opseg Module Federationa i izbjegli uobičajene zamke, razmotrite ove najbolje prakse:

1. Centralizirajte dijeljene ovisnosti: Odredite primarnu aplikaciju (često kontejner ili posvećenu aplikaciju za dijeljene biblioteke) kao izvor istine za uobičajene, stabilne ovisnosti poput okvira (React, Vue, Angular), UI biblioteka komponenti i biblioteka za upravljanje stanjem.
2. Definirajte široke raspone verzija: Koristite SemVer raspone (npr. '^18.0.0') za dijeljene ovisnosti u primarnoj aplikaciji za dijeljenje. To omogućuje drugim aplikacijama korištenje kompatibilnih verzija bez prisiljavanja na stroga ažuriranja u cijelom ekosustavu.
3. Jasno dokumentirajte dijeljene ovisnosti: Održavajte jasnu dokumentaciju o tome koje se ovisnosti dijele, njihove verzije i koje su aplikacije odgovorne za njihovo dijeljenje. To pomaže timovima da razumiju graf ovisnosti.
4. Pratite veličine paketa: Redovito analizirajte veličine paketa svojih aplikacija. Dijeljeni opseg Module Federationa trebao bi dovesti do smanjenja veličine dinamički učitanih dijelova (chunks) jer se uobičajene ovisnosti eksternaliziraju.
5. Upravljajte nedeterminističkim ovisnostima: Budite oprezni s ovisnostima koje se često ažuriraju ili imaju nestabilne API-je. Dijeljenje takvih ovisnosti može zahtijevati pažljivije upravljanje verzijama i testiranje.
6. Koristite `eager: true` promišljeno: Iako `eager: true` osigurava da se ovisnost rano učita, prekomjerna upotreba može dovesti do većih početnih učitavanja. Koristite ga za kritične biblioteke koje su neophodne za pokretanje aplikacije.
7. Testiranje je ključno: Temeljito testirajte integraciju svojih mikro-frontendova. Osigurajte da se dijeljene ovisnosti ispravno učitavaju i da se sukobi verzija rješavaju elegantno. Automatizirano testiranje, uključujući integracijske i end-to-end testove, je vitalno.
8. Razmislite o monorepo-ima radi jednostavnosti: Za timove koji započinju s Module Federationom, upravljanje dijeljenim ovisnostima unutar monorepo-a (koristeći alate poput Lerne ili Yarn Workspaces) može pojednostaviti postavljanje i osigurati dosljednost. Opcija `packageDir` je ovdje posebno korisna.
9. Rješavajte rubne slučajeve s `shareKey` i `shareScope`: Ako naiđete na složene scenarije verziranja ili trebate izložiti različite verzije iste biblioteke, istražite opcije `shareKey` i `shareScope` za detaljniju kontrolu.
10. Sigurnosna razmatranja: Osigurajte da se dijeljene ovisnosti dohvaćaju iz pouzdanih izvora. Implementirajte sigurnosne najbolje prakse za svoj proces izgradnje i implementacije.

Globalni utjecaj i razmatranja

Za globalne razvojne timove, Module Federation i njegov dijeljeni opseg nude značajne prednosti:

• Dosljednost u različitim regijama: Osigurava da svi korisnici, bez obzira na njihovu geografsku lokaciju, doživljavaju aplikaciju s istim temeljnim ovisnostima, smanjujući regionalne nedosljednosti.
• Brži ciklusi iteracije: Timovi u različitim vremenskim zonama mogu raditi na neovisnim značajkama ili mikro-frontendovima bez stalne brige o dupliciranju uobičajenih biblioteka ili međusobnom ometanju u vezi s verzijama ovisnosti.
• Optimizirano za različite mreže: Smanjenje ukupne veličine preuzimanja putem dijeljenih ovisnosti posebno je korisno za korisnike na sporijim ili ograničenim internetskim vezama, koje su česte u mnogim dijelovima svijeta.
• Pojednostavljeno uvođenje novih članova: Novi programeri koji se pridružuju velikom projektu mogu lakše razumjeti arhitekturu aplikacije i upravljanje ovisnostima kada su uobičajene biblioteke jasno definirane i dijeljene.

Međutim, globalni timovi također moraju biti svjesni:

• CDN strategije: Ako se dijeljene ovisnosti hostiraju na CDN-u, osigurajte da CDN ima dobar globalni doseg i nisku latenciju za sve ciljne regije.
• Podrška za izvanmrežni rad: Za aplikacije koje zahtijevaju izvanmrežne mogućnosti, upravljanje dijeljenim ovisnostima i njihovim keširanjem postaje složenije.
• Regulatorna usklađenost: Osigurajte da je dijeljenje biblioteka u skladu s relevantnim licencama za softver ili propisima o privatnosti podataka u različitim jurisdikcijama.

Uobičajene zamke i kako ih izbjeći

1. Neispravno konfiguriran `singleton`

Problem: Zaboravljanje postavljanja singleton: true za biblioteke koje bi trebale imati samo jednu instancu.

Rješenje: Uvijek postavite singleton: true za okvire, biblioteke i uslužne programe koje namjeravate jedinstveno dijeliti među svojim aplikacijama.

2. Nedosljedni zahtjevi za verziju

Problem: Različite aplikacije specificiraju znatno različite, nekompatibilne raspone verzija za istu dijeljenu ovisnost.

Rješenje: Standardizirajte zahtjeve za verziju, posebno u kontejnerskoj aplikaciji. Koristite široke SemVer raspone i dokumentirajte sve iznimke.

3. Prekomjerno dijeljenje nebitnih biblioteka

Problem: Pokušaj dijeljenja svake male uslužne biblioteke, što dovodi do složene konfiguracije i potencijalnih sukoba.

Rješenje: Usredotočite se na dijeljenje velikih, uobičajenih i stabilnih ovisnosti. Manje, rijetko korištene uslužne programe možda je bolje uključiti lokalno kako bi se izbjegla složenost.

4. Neispravno rukovanje datotekom `remoteEntry.js`

Problem: Datoteka `remoteEntry.js` nije dostupna ili se ne poslužuje ispravno aplikacijama koje je koriste.

Rješenje: Osigurajte da je vaša strategija hostiranja za udaljene unose robusna i da su URL-ovi navedeni u `remotes` konfiguraciji točni i dostupni.

5. Ignoriranje implikacija `eager: true`

Problem: Postavljanje eager: true na previše ovisnosti, što dovodi do sporog početnog vremena učitavanja.

Rješenje: Koristite eager: true samo za ovisnosti koje su apsolutno kritične za početno renderiranje ili temeljnu funkcionalnost vaših aplikacija.

Zaključak

Dijeljeni opseg JavaScript Module Federationa moćan je alat za izgradnju modernih, skalabilnih web aplikacija, posebno unutar mikro-frontend arhitekture. Omogućavanjem učinkovitog dijeljenja ovisnosti, rješava probleme dupliciranja koda, napuhanosti i nedosljednosti, što dovodi do poboljšanih performansi i lakšeg održavanja. Razumijevanje i ispravno konfiguriranje opcije shared, posebno svojstava singleton i requiredVersion, ključno je za otključavanje ovih prednosti.

Kako globalni razvojni timovi sve više usvajaju mikro-frontend strategije, ovladavanje dijeljenim opsegom Module Federationa postaje od presudne važnosti. Pridržavanjem najboljih praksi, pažljivim upravljanjem verzijama i provođenjem temeljitog testiranja, možete iskoristiti ovu tehnologiju za izgradnju robusnih, visokoučinkovitih i održivih aplikacija koje učinkovito služe raznolikoj međunarodnoj korisničkoj bazi.

Prigrlite moć dijeljenog opsega i otvorite put za učinkovitiji i suradnički web razvoj u vašoj organizaciji.